DeepWiki

01.c - Data-Flow-&-Correlation

Relevant source files

This document explains the critical data flow that links payment to repository access in godeep.wiki. The system faces a fundamental challenge: a customer pays via Stripe, then separately connects their GitHub account, and the owner must correlate these two independent events without a database. This page details how the session_id serves as the correlation key, how cookies temporarily bridge the payment and GitHub connection phases, and why manual log inspection remains necessary for operation.

For the complete payment processing flow, see Payment Processing. For GitHub authentication details, see Authentication & GitHub Integration. For the automation pipeline that consumes correlated data, see Automation System.

The system processes two asynchronous, independent events:

EventSourceIdentifying DataTimestamp
Payment completionStripe webhooksession_id, customer_emailEvent time
GitHub connectionOAuth callbackinstallation_id, github_usernameCallback time

Without a database, these events cannot be automatically linked. The system must preserve correlation data through the user's browser session and reconstruct the relationship via log analysis.

Sources: CLAUDE.md L44-L50

The Stripe session_id serves as the golden thread linking payment to repository access. This identifier is:

  • Generated by Stripe during checkout session creation
  • Immutable throughout the user journey
  • Logged at every critical correlation point
  • Used by the owner to match payment records with repository installations

Sources: app/api/auth/github/callback/route.ts L39-L50

CLAUDE.md L46-L50

The system uses HTTP cookies to preserve the session_id during the GitHub OAuth redirect flow, which would otherwise lose query parameters.

The github_oauth_state cookie contains a Base64-encoded JSON object:

FieldPurposeExample
nonceCSRF protectionUUID v4 random string
sessionIdPayment correlationcs_test_a1b2c3d4e5f6...

Cookie Configuration:

  • Path: / (application-wide)
  • MaxAge: 3600 seconds (1 hour)
  • HttpOnly: true (prevents XSS access)
  • Secure: true in production (HTTPS only)

State Verification: app/api/auth/github/callback/route.ts L26-L37

implements CSRF protection by verifying the state parameter from GitHub matches the cookie value before proceeding.

State Decoding: app/api/auth/github/callback/route.ts L39-L50

extracts the session_id from the Base64-encoded state:

const stateData = JSON.parse(Buffer.from(state, 'base64').toString('utf-8'))stripeSessionId = stateData.sessionId

Sources: app/api/auth/github/callback/route.ts L23-L50

CLAUDE.md L46-L50

The system creates correlation data at three critical points, all logged to Vercel's stdout (accessible via Vercel dashboard or CLI):

app/api/webhooks/stripe/route.ts L48-L59

logs payment completion:

=======================================================================
💰 NEW PAYMENT RECEIVED
=======================================================================
Session ID: cs_test_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
Amount: $10.00
Customer Email: user@example.com
Payment Status: paid
Timestamp: 2024-01-15T10:30:00.000Z
=======================================================================

app/api/auth/github/callback/route.ts L99-L111

logs GitHub connection:

================================================================================
🎉 NEW GITHUB APP INSTALLATION
================================================================================
Stripe Session ID: cs_test_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6
Installation ID: 12345678
GitHub Username: johndoe
GitHub Email: johndoe@example.com
GitHub User ID: 987654
User Name: John Doe
Setup Action: install
Timestamp: 2024-01-15T10:32:00.000Z
================================================================================

Both webhook and callback send notifications to ntfy.sh with the "Match ID" (last 12 characters of session_id) for easier visual correlation:

Payment Notification: app/api/webhooks/stripe/route.ts L61-L79

Step 1: Payment Received - GoDeep.wiki

💰 Amount: $10.00
📧 Customer: user@example.com
🔑 Match ID: m3n4o5p6
⏰ Time: 1/15/2024, 10:30:00 AM

GitHub Connection Notification: app/api/auth/github/callback/route.ts L113-L137

Step 2: GitHub Connected - GoDeep.wiki

🔑 Installation ID: 12345678
📧 Customer: johndoe@example.com
🔑 Match ID: m3n4o5p6
⏰ Time: 1/15/2024, 10:32:00 AM

Sources: app/api/webhooks/stripe/route.ts L48-L81

app/api/auth/github/callback/route.ts L99-L137

Sources: app/api/webhooks/stripe/route.ts L22-L92

app/api/auth/github/callback/route.ts L1-L149

CLAUDE.md L32-L50

The owner performs manual correlation through the following steps:

  1. Access Stripe Dashboard → Payments
  2. Find the $10.00 payment for "DeepWiki Analysis"
  3. Copy the Session ID (format: cs_test_... or cs_live_...)
  4. Note the Customer Email
  1. Access Vercel project → Logs
  2. Search for: session_id: cs_test_... (the full session ID)
  3. Locate the log entry containing both: * Stripe Session ID: cs_test_... * Installation ID: 12345678

From the log entry matching the session ID, extract:

  • installation_id (numeric identifier)
  • GitHub Username (for verification)
  • GitHub Email (cross-check with Stripe email)

If the owner subscribes to ntfy notifications, they can visually match:

  • Payment notification Match ID: Last 12 characters of session_id
  • GitHub notification Match ID: Same last 12 characters
  • Both notifications should show matching customer email/username

The logs provide all necessary correlation data:

Data PointSourceUsed For
session_idStripe + OAuth callbackPrimary correlation key
customer_emailStripe webhookCustomer identification
installation_idOAuth callbackRepository access
github_usernameOAuth callbackVerification
github_emailOAuth callbackCross-verification
timestampBoth logsTemporal validation

Sources: CLAUDE.md L35-L43

app/api/auth/github/callback/route.ts L99-L111

To simplify visual correlation, the system includes a "Match ID" in ntfy notifications—the last 12 characters of the session_id.

Payment notification: app/api/webhooks/stripe/route.ts L67

const sessionShort = session.id.slice(-12)

GitHub notification: app/api/auth/github/callback/route.ts L118

const sessionShort = stripeSessionId ? stripeSessionId.slice(-12) : 'Not linked'

The Match ID enables quick visual correlation when monitoring ntfy notifications:

NotificationMatch IDPurpose
Step 1: Paymentm3n4o5p6Indicates payment received
Step 2: GitHubm3n4o5p6Confirms same customer

When both notifications show the same Match ID, the owner knows:

  1. The customer completed both steps
  2. The correlation is automatic (no log search needed)
  3. The installation_id in Step 2 corresponds to the payment in Step 1

Limitation: The Match ID is only useful when monitoring ntfy in real-time. For historical correlation, full log search is still required.

Sources: app/api/webhooks/stripe/route.ts L61-L79

app/api/auth/github/callback/route.ts L113-L137

The system can experience correlation failures in several cases:

Symptoms:

  • Payment log exists with session_id
  • No corresponding GitHub installation log
  • Customer never clicks "Connect GitHub" button

Detection:

  • Stripe payment exists but no matching installation_id in logs
  • Time gap > 24 hours between payment and expected GitHub connection

Resolution:

  • Contact customer via email from Stripe
  • Request GitHub connection completion
  • May require refund if customer cannot provide repository access

Symptoms:

  • Payment log exists
  • GitHub installation log exists but shows Stripe Session ID: NOT PROVIDED
  • User took > 1 hour between payment and GitHub connection

Detection: app/api/auth/github/callback/route.ts L103

logs NOT PROVIDED when state decoding fails

Resolution:

  • Manual correlation via customer email and timestamp
  • Match Stripe email with GitHub email/username
  • Match timestamps (within reasonable window)

Symptoms:

  • Same github_username appears multiple times
  • Multiple installation_id values for same user
  • Unclear which installation corresponds to which payment

Detection:

  • Log search returns multiple entries for same username
  • Timestamps span multiple days

Resolution:

  • Use timestamp proximity (payment time vs. installation time)
  • Cross-reference customer email from Stripe with GitHub email
  • Contact customer if ambiguous

Sources: app/api/auth/github/callback/route.ts L39-L50

app/api/auth/github/callback/route.ts L103

The system deliberately avoids database usage for several architectural reasons:

AspectDatabase ApproachLog-Based Approach (Current)
InfrastructureRequires DB service (Postgres, Redis)Uses Vercel's built-in logging
CostMonthly DB hosting feesFree (included in Vercel)
ComplexitySchema migrations, connection poolingZero additional configuration
Data retentionMust implement backupsVercel handles log retention
GDPR complianceMust implement data deletionLogs naturally expire
Failure modesDB connection failuresLogs always available
Volume scalingRequires sharding at scaleNot designed for scale

Advantages of no database:

  • Zero maintenance overhead
  • Simplified deployment (single Vercel project)
  • No connection management or pooling
  • No database credentials to secure
  • Automatic log rotation and retention

Disadvantages of no database:

  • Manual correlation required (not automatable)
  • Historical queries require log search
  • No queryable payment history
  • Correlation fails if logs are lost
  • Does not scale beyond ~10-20 customers/day

This design reflects the system's philosophy: prioritize simplicity and manual operation over automation and scale.

Sources: CLAUDE.md L1-L11

High-level diagrams (Analysis sections)

The correlation system operates through these principles:

  1. session_id is the primary correlation key linking payment to repository access
  2. Cookies bridge the OAuth flow preserving session_id during GitHub redirects
  3. Logs are the permanent record containing all correlation data
  4. Manual inspection is required for matching payments to installations
  5. Match ID provides convenience for real-time ntfy monitoring
  6. No database simplifies operation at the cost of automation
  7. System assumes low volume (~10-20 customers/day maximum)

The correlation mechanism is the critical pathway that enables the owner to access customer repositories after payment completion. Understanding this flow is essential for operating and troubleshooting the system.

Sources: CLAUDE.md L32-L50

app/api/auth/github/callback/route.ts L1-L149

app/api/webhooks/stripe/route.ts L1-L92

Refresh this wiki

Last indexed: 23 November 2025 (922b35)

On this page

Ask Devin about godeep.wiki-jb

01.c - Data-Flow-&-Correlation | DeepWiki | godeep.wiki